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0 The present plant operating invention employs a modeling system that arranges the model in a hierarchical 
structure of communicating and independently executing object modules controlled by an overall supervisor. 
Each object represents a component or a system and includes an object controller which communicates with 
other object modules, an object error checker and an object model. The objects communicate through a 
database accessible by all objects. The structure of the object module and the hierarchical structure itself are 
standardized allowing new components or systems to be added by adding a standard object module which 
includes an object model that is unique to the object being modeled. The controller for an object causes 
subobjects upon which the object model depends for data to be executed prior to execution of the object model. 
Such bottom up model traversal insures that models do not execute until all needed data is available. The error 
check module checks the controller and model modules to make sure they are executing properly. The object 
model includes a deterministic equation based component aging model, a statistical based component aging 
model and expert mles that combine the deterministic and statistical model with the knowledge of experts to 
determine the current state of the object and make recommendations concerning future actions concerning the 
object. A maintenance module is also included along side the supervisor that allows maintenance actions for the 
objects to be taken into consideration. 
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IMPROVED PLANT OPERATING SYSTEM EMPLOYING A DETERMINISTIC, PROBABILISTIC AND SUBJEC- 
TIVE MODEUNG SYSTEM 



The present invention relates to plant operating systems and more particularly to such systems that 
employ a computer-based modeling system that provides for improved overall performance of plant 
components and systems that degrade with age. The system involves a system model that combines 
expert rules, probabilistic models, and deterministic models to evaluate and predict the effect of component 

5 aging on component life extension, operational readiness, maintenance effectiveness, and safety of a 
system along with evaluating and identifying maintenance and operational actions that provide improved 
overall performance of the plant. 

Current methods used to operate complex plants or systems, such as nuclear power plants based on 
plant modeling used to detemiine age degradation of the various subsystems within the complex plant are 

70 inefficient, time consuming, and many times unreliable. Each component of the plant or complex system is 
analyzed separately to obtain a numerical indication of its state. The numerical value must then be 
interpreted by a plant operator to determine the current and potential state of the component. To determine 
the overall state of the plant, each individual component of the plant must be analyzed in relation to the 
other components, for example, the separate parts of a reactor coolant pump must be combined and 

75 analyzed together to determine the actual state of the reactor coolant pump. The current methods 
emphasize the separate components of a plant, instead of how and why these components interact. 

Many current plant management systems employ modeling methods using a deterministic approach 
which reviews the physical characteristics of a plant, for example, temperature, pressure, etc.. and evaluates 
the plant solely on the basis of this quantitative information. Other modeling methods use a statistical and 

20 probabilistic approach to compare the present state of a component with its past history and to determine 
what the component and the plant might do next. The current plant modeling methods fall to emphasize an 
heuristic approach to consider the dynamic interaction between plant components or subsystems when 
detennining the present and future performance of a plant and plant operation and management is thus 
correspondingly deficient. 

25 The present invention provides a plant system that operates on the basis of deterministic, statistical and 
probabilistic modeling methods combined with heuristic expert system prediction methods In modeling 
plant systems and their components. 

The system accurately and reliably improves the performance of aging systems particularly aging 
power plants. Further, the system reduces or delays the need for replacement of plant components. 
30 monitors the effects of aging on plant safety. Improves the reliability and availability of the plant, avoids 
catastrophic plant failures and optimizes maintenance and repair of the plant. 

The system employs a model in a hierarchical structure of communicating object modules controlled by 
an overall supervisor module. Each object module represents a component or a system and Includes an 
object controller which communicates with other object modules, an object error checker and an object 
35 model. The structure of the object module and the hierarchia! structure itself are standardized allowing new 
components or systems to be added by adding a standard object module which includes a unique object 
model. The object model includes a deterministic equation based component aging model, a statistical 
based component aging model and expert rules that combine the detenministic and statistical models with 
the knowledge of experts to determine the cun-ent state of the object and make recommendations 
40 concerning future plant operating actions concerning the object. A maintenance module is also included, 
along side the supervisor module, that allows maintenance actions for the objects to be reflected in overall 
plant operation and management. 

Fig. 1A illustrates how deterministic, probabilistic, statistical and heuristic methods are combined; 
Rg. IB is system level diagram of the invention; 
45 Rg. 2 illustrates the initiation and execution control and data flow in the present invention; 
Fig. 3 depicts the initiation routine of each object in the present invention; 
Fig. 4 illustrates the supervisor module 14/50; 

Rg. 5 illustrates the controller module 26 of each object being simulated; 
Rg. 6 depicts a model module 30 for each object; 
50 Rg. 7 shows a preferred arrangement for a model module 30; 
Rg. 8 illustrates the operation of the error check module 28; 
Rg. 9 depicts the user control module 18; 
Rg. 10 illustrates the screen display module 18; 
Rg. 11 shows the function of the maintenance module 20; and 
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Figs. 12 and 13 are examples of displays provided during a simulation. 

In the operation and management of a nuclear or other plant, there are various subsystems and 
components that are employed in accordance with a system design to produce the desired operating 
results. In the case of nuclear power plants, for example, electric power is generated. 

5 Various considerations enter into the design of a system for operating the plant, including the control of 
subprocesses to meet collective operating needs and the management of subsystem and component 
operations to reflect or mitigate aging effects. 

In the present case, a modeling system is employed as a part of a plant operating system and it is 
designed to accurately and reliably improve the performance of aging power plants. The modeling system 

10 provides a method to evaluate the effects of age degradation on a power plant, before they manifest 
themselves, and to make recommendations for implementation in the plant operating system to mitigate 
these aging effects. The overall system is able to anticipate problems before they occur and to take 
maintenance, testing, replacement, or inspection actions on the basis of recommendations generated by a 
system simulation. The modeling system provides continuous monitoring of both the risk and the probability 

75 of failure, and the probable life left of any particular component or system within the plant. 

The modeling system of the present Invention has a modular and distributed design. It uses an 
Integrated modeling approach by combining the deterministic, statistical, probabilistic and heuristic ap- 
proaches to problem solving. Integrated modeling provides an accurate and practical measure of the state 
of a particular component or system. It combines and analyzes all the factors which might affect the 

20 component or system under consideration. Because of the distributed modular design, the modeling system 
can be used as a generic shell and applied to any component or system within a power plant. To enhance 
flexibility the system is designed with blank stubs which reserve space in the system for additional 
modules. 

The function of the modeling system In the plant operating system is to collect, store, and display data 
25 representative of the operating condition of the plant components and systems. The modeling system then 
calculates the expected life of each component and each subsystem that Includes the components. The 
modeling system also makes recommendations directing the performance or restraint of performance of 
certain procedures in the plant operating system. The modeling system is further designed to emulate the 
analytical processes of an engineer. The modeling system reviews the historical data relating to the 
30 component or system, evaluates age degradation and extrapolates into the future to develop a life profile 
including measures of life left, useful life. etc. The modeling system predicts the life profile of components 
or systems by considering several factors including maintenance schedules, subcomponent and part 
quality, personnel availability, and economic resources. A life profile is an indication of the level of 
performance of a component or subsystem from its installation to the present and through the expected or 
35 predicted out-of-service date. The profiles are similar to tracking devices and operate in an iterative fashion 
and summarize all the substates a component or subsystem passes through, over time, to reach a certain 
state. The profiles are extremely useful visual tools In determining whether plant safety parameters are 
being satisfied. 

The plant operating system employs a model that combines the deterministic, statistical, probabilistic 

40 and heuristic approaches to problem solving. The deterministic approach models fundamental physical 
processes of a system to predict behavior for assumed conditions. The statistical and probabilistic approach 
models the historical behavior of a particular component or system. The heuristic approach is a qualitative, 
high level approach to problem solving which captures human expertise to model the dynamic interaction of 
components and systems. By combining these three approaches to problem solving, a realistic and 

45 comprehensive picture of the component or system can be obtained. The information thereby provided 
directly relates to the physical, historical, and actual status of the component or subsystem making it useful 
and practical to the operator. 

The system displays and records the evaluated information on a digital display screen. The output can 
be continuously displayed in analog form, using meters, graphs, and moving displays such as a component 

50 life profile graph, for increased user friendliness or simple numbers can be output 

To combine the deterministic, probabilistic, statistical and heuristic approaches the model of each 
object should be divided into two distinct sections that take advantage of the programming language 
capabilities of todays languages. One section, as illustrated in Fig. la which handles the heuristic 
determinations and deterministic calculations, is preferably an expert system module 4 that performs state 

55 evaluations. This module 4 performs rule based (expert system) detemninations and simple calculations to 
determine the state of the object from all of the variables available which must be evaluated to determine 
the state. The second section 6 uses deterministic calculations, which can be statistically or probabilistically 
based, to extrapolate the change in condition of the object during a predetermined interval from the state 
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determined by module 4. Heuristic rules can also be used to choose the deterministic calculations that 
extrapolate from the determined state to the extrapolated condition. This section 6 is typically implemented 
in a scientific calculation programming language. The cycle of state evaluation 4 and extrapolation 6 in 
predetermined time increments continues as the aging of the object is simulated over time. Some of the 

5 variables produced by the extrapolation are used in the next state detenmination. The extrapolation 
produces data tfiat can be used by otiier objects, that can be changed by the user to simulate external 
condition changes and that can be output to be displayed to tiie user as the simulation progresses. In 
addition to controlling the sequence of object simulation shown in Rg. la, heuristic rules can also be used 
to determine tiie interaction of all the objects in the system. 

10 The computer system has two basic levels, a system level 10 and model levels 12 as illustrated in Rg. 
lb. The system level contains supervisor 14. user control 16. screen display 18. maintenance 20. error 
check 22, and data archive 24 modules . The supervisor module 14 controls the execution sequence of the 
other modules and initiates execution of tiie models in the model levels 12. The user control module 16 
permits the operator to select the objects modeled, i.e.. the components or systems; the profiles, i.e. useful 

IS service, safety margin, etc.; and the system parameters. I.e.. temperature, pressure, etc.. for analysis and 
display during a particular run. It also provides the operator witii the ability to start, stop, pause, save, or 
restore a particular run. The screen display module 18 accesses and displays the collected data and 
recommendations of the modeling system from a common database. The maintenance module 20 makes 
changes in the model database which simulate component replacement or repair. The supervisor error 

20 check module 22 monitors the user control module 16. screen display module 18. the maintenance test and 
inspection module 20 and the data archive module for errors. The supervisor error check module 22 
performs the same functions as other lower level error check modules, as will be discussed in more detail 
later, and notifies the user module 16 and supervisor 14 when any errors are detected. The ability to access 
data archives using module 24 gives an operator the flexibility to store result data for selected objects for a 

25 particular run. and retrieve the information at a later time. Each object model on each of the model levels 12 
contains tiiree object modules designated controller module 26. enror check module 28 and model module 
30. The controller module 26 determines and controls the processes to be run on each of the systems, 
components, or subcomponents. The en-or check module 25 is an independent monitoring module which 
monitors and scans the system for errors and excessive CPU completion times. It passes the acquired error 

30 data to the controller module 26 and the operator. The model module 30 represents the actual system, 
component, and subcomponent models of the plant. This module 30 takes input data and performs 
deterministic, probabilistic and expert system functions to provide the various profile data and recommenda- 
tions, r- u I.- * 

The modeling system has the capability of switching analysis from one object to anotfier. Each object 

35 has a separate model module for object evaluation and each system In the plant is also represented by an 
object, tiiat Is. the objects represent the system 32 as well as components 34 of the system. Each of the 
objects relates back to a higher level object as shown by the connection of component object 34 to system 
object 32 and thereon to plant object 36. The modeling system uses a standardized modular stmcture. i.e.. 
the model is divided into a plant level, a systems level, the systems are divided into components, and tiie 

40 components are divided into subcomponents to allow each part of the plant to be analyzed separately and 
as a part of the whole plant. The modular structure provides the modeling system with the necessary 
flexibility and growtti potential to allow the continuous expansion of the systems and their components 
through tiie addition and replacement of modules. Each object 32. 34 or 36, representing a specific 
component or system witiiin the plant, also has a standard structure. The modular structure minimizes tiie 

45 need to recompile, retest, and recede information about each component or system. 

The plant operating system includes data input for tiie system models including plant operating 
characteristics, preventative maintenance schedules, predefined time periods for evaluation, tiie present 
state of the equipment, etc.. The information is processed by the modeling system to obtain output values 
for implementation in plant operation Including the life left, tiie failure probabilities, the useful service, and 

so the life profiles of the systems and components. The modeling system takes into consideration the increase 
in the expected life of a plant, produced by replacing and repairing parts, when determining the failure 
probability of a plant. 

The modeling system is preferably implemented in a computer such a Digital Equipment Corporation 
(DEC) Microvax using an operating system which allows each module in tiie system to execute as an 
55 Independent process such as tiie DEC VMS operating system, where the processes are primarily written in 
a language such as FORTRAN which will allow easy system control. Each model module 30 is written in an 
expert system language such as 0PS5 which will allow expert rule type determinations to be easily made 
and which is designed to allow the expert system to call FORTRAN routines to obtain deterministic. 
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probabilistic and statistical model predictions, thereby allowing the model module builder to create expert 
rules in a language suitable for expert programs and to create prediction equations In a language suitable 
for such equations. During the model initialization process the supervisor 50. as illustrated in Fig. 2 initiates 
the plant object 54. The plant object controller within the plant object 54 initiates the model module 30 and 
s error check module 28 in the plant object 54 and then proceeds to initiate any subobjects, for example 
system objects 56 and 58. which the plant object 54 depends upon for input data. These subobjects are 
generally system objects 56 and 58 however the subobjects can be component objects. Each subobject 
such as the system object 56 initiates its own model module and en-or check module and then proceeds to 
initiate any subobjects. such as component objects 60 and 62, upon which it depends. These component 
10 objects also initiate their own en-or check and model modules as well as any subcomponent objects 64 and 
66, When a lower level object such as object 64 has been initiated it communicates the status of this task 
completion to the higher level object, such as 62. When all of the objects have been Initiated as indicated 
by each of the subobjects informing a higher level object which informs a further higher level object, the 
supervisor 50 initiates a simulation cycle. A simulation cycle requires that all lower level objects complete a 
15 simulation execution cycle before a higher level object can complete execution. The higher level object 
initiates the lower level object from a list of objects which it controls. In this way initiation of the object tree 
Is controlled from the top down while actual execution is from the bottom up. To add objects to the system, 
it is only necessary to add the new object to the objects list contained in the parent object. Input data in the 
form of component initialization or current state data can be provided individually to each one of the 
20 objects, where data flow is illustrated in Fig. 2 by dashed lines, or the Input data can be stored in a 
common data pool 68. Result data produced by an object such as object 64 and 66 Is stored In the 
common data pool 68 where it can be accessed by any object at any level, thereby providing data 
communication between objects. For example, a subcomponent object may be representing the bearings in 
a feedwater pump while the component object represents the pump which includes not only the bearings 
25 but a drive motor component. By designing the modeling system so that result data is stored in a common 
data pool 68 new objects and communication pathways between the new objects can be easily created. 

The routine within the controller module 26 of each object (32, 34 or 36) which controls initiation of the 
object and its subobjects Is illustrated in Fig. 3. Once the initiation process within the object controller 26 is 
started 80, it spawns 82 the model module 30, error check module 28 and subobject modules using a list of 
30 subobjects on which the object depends for data. For example, the coolant pump object could spawn a 
coolant pump bearing object, a motor winding object and an impeller object. The spawning process is a 
conventional process within the VMS operating system and merely requires that a message be transmitted 
to the operating system requesting that a named process be started. The names of the processes to be 
spawned are obtained from the list of subobjects. To add a subobject to the objects in a system the name 
35 of the subobject only needs to be added to the list in the parent object. The name of each process is a 
unique identifier which also identifies the data storage area for the process where the data storage area 
contains initial conditions, the maintenance schedule and stores result data. Once the spawning process is 
started for all the modules, the initiation routine within the controller 26 awaits interrupts 84 from the 
processes that have been started. When an interrupt occurs, the process named in the intermpt message is 
40 used to access the list of subobject processes and the process providing the interrupt is flagged 86 
indicating that it Is completed. Next the initiation routine determines 88 whether all of the processes are 
done, by reviewing the list to see if all subobject initiation flags have been set, if not the process returns to 
await 84 further interrupts. If the processes are all initiated, the routine interrupts 90 its parent object by 
sending an initialization complete message, which includes the name of the process that has finished 
45 initialization, to the parent object through the operating system in a conventional manner. This interrupt 
message transmission is followed by the entry Into a wait state 92 in which the controller 26 awaits an 
interrupt requesting a simulation cycle. By initiating all processes as independent processes and placing 
them in interruptable wait states, the system will only execute those processes that are needed and 
therefore the execution efficiency of the modeling system is improved because all processes are not active 
50 at the same time. 

The next step in the simulation process is to ain the modeling system based on initial conditions and 
expected operating conditions for a period of time designated by the user such as forty years which is the 
typical life of a power plant. During a run various outputs are provided to the user which indicate the state of 
the com ponents of the plant and any maintenance which is simulated as being performed on the various 
65 components. During a model run the user can Intemjpt execution to change the state of various 
components, such as indicating complete replacement, so that the effects of unscheduled maintenance can 
be determined. At the end of a run, the user reviews the various graphs and statistics produced for the 
various components, such as the remaining life of the plant or the components or the risk of plant or 
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component failure. Once this review is completed, the user can input new initial conditions or new operating 
conditions or a new maintenance schedule and perfonm another simulation. In this way. the user can model 
various maintenance responses to changing plant conditions to optimize a maintenance schedule as well as 
to enhance the life of the plant. By allowing the user to change initial conditions, the actual state of the plant 

5 at the time of the simulation can be incorporated into the model making future projections as accurate as 
possible at the time of the simulation. Periodic simulations, such as once every month, will allow the user to 
fine tune maintenance and plant life extension strategies as the plant ages because the initial condition of 
the components will reflect actual component condition at the monthly simulation times. 

At the start 100 of a simulation the supervisor module 14/50. as illustrated in Fig. 4, obtains initial 
.70 condition data either from a file designated by the user or from initial conditions keyed in by the user. For 
example, the initial condition data for an oil pump could be (100. 23.3. normal, high, normal, a102. 0. 20000) 
where, respectively. 100 Is pressure in pounds per square inch produced by the pump, 23.3 is temperature 
in degrees C of the oil. normal indicates oil flow is in a normal range, high indicates a high corrosive 
particulate count In the oil. normal indicates normal pump speed. a102 is the model number of the pump, 0 

75 indicates the cun-ent time the pump has been running at the beginning of the Simula tlon and 20000 is the 
maintenance interval for the pump. Of course the order and specifics of the data provided initially will vary 
depending on the object being modeled, however, variables for the cun-ent time and the maintenance 
interval will always be Included. Once the initial conditions are obtained 102 the process checks 104 start, 
stop, pause and other flags and if one of these flags is set. the process executes an appropriate routine. For 

20 example, if the stop flag is detected, the system will stop and permit a data Input routine to be executed 
which will allow the user to change the maintenance data record, thereby interrupting the run to perform an 
unscheduled maintenance. For example, such a conventional routine would ask the user to identify the 
object of interest, using the object name the routine would read out the object data in the common data 
base 68. allow the user to change the data and restore the data to the data base 68. Next the supervisor 

25 checks 106 the error check module 22 by examining an indicator (flag) in the common data area 68 which 
is set by the error check module 22 when a problem has occurred. If this flag is set the supervisor module 
14 stops execution and thereby transfers control to a display routine which will provide the user with 
information concerning the error detected by the error check module 22. Next the supervisor increments 
108 the time variable by a predetermined amount. The amount or time increment depends on the physical 

30 characteristics of objects being simulated, the maintenance periods of the objects and the desired 
resolution of the output. With respect to the physical characteristics of the objects, It is preferable that the 
time increment be shorter than the shortest duration of a physical phenomenon of the objects being 
simulated. It is also preferable that the time increment be shorter than the shortest maintenance interval 
othenwise maintenance activities could be skipped. It is also preferable that the time increment be set such 

35 that a fine resolution will be obtained so that the results will be more accurate. However, minimizing the 
time increment increases the run time for a simulation. Since the simulation can be run off line (i.e. not real 
time), turn around is generally not a problem. For power plants a time increment of 24 hours is preferred. At 
this step 108 the total elapsed time is also compared to tfie time set for the simulation and. if the elapsed 
time is equal to or greater than the set time, the program stops the simulation. Next the maintenance 

40 module 20 is executed 110 which will update the mode and state variables of the different objects being 
modeled in the common data area 68 to indicate that maintenance has occurred, if the time of the 
simulation is coincident with a scheduled maintenance event. For example, if replacement type maintenance 
is indicated in the maintenance schedule the remaining life of the component being replaced is set to 100% 
in the common data area, however, if component refurbishment is performed the remaining life may be set 

45 at 80%. Execution of the maintenance module 20 is accomplished by conventionally providing an 
appropriate message to the operating system directed to awakening the maintenance module. The 
supervisor then v/aits 112 for an intenrupt from the maintenance module 20 indicating that the maintenance 
cycle has been completed. Next the supervisor routine 14/50 runs or starts the highest object in the model 
which is the plant object in the example discussed herein. This is accomplished by providing a conventional 

50 message to the operating system specifying the task to be run. Once again the supen/isor waits 116 until 
the highest object indicates via an interrupt that this simulation cycle has been completed. The process 
then checks 118 an archive data flag to determine whether it is set and. if so, the archive module 24 is 
executed 120 followed by a wait 122 for an interrupt indicating that the results of this time increment in the 
simulation cycle have been stored on an appropriate medium such as a floppy disk. Next the screen 

55 display module 18 Is executed 124 and the graphs and statistics on the current state of the simulation are 
provided to the user, after which another wait state 126 is entered. \Amen the wait state 126 from the 
running of the screen display module 18 is finished, as signified by an interrupt from the screen display 
module 18. the supervisor process cycles back to perform another time increment of the simulation. 
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Each object (32. 34 or 36) includes a controller module simulation control routine such as illustrated in 
Rg. 5. Each controller module 26 is started 140 by the parent process providing a conventional start 
message to the operating system. The first step by the controller module is the check 141 to determine 
whether the en^or check module 28 for the object is executing by examining the status of the error check 
6 module 28, continuously updated by the system (VMS). Prior or subsequent to the error check 141, the 
controller preferably sets an indicator in the common database 68 that indicates that the controller module 
for this object has started a simulation cycle. It is also possible for this step to store the start time of the 
cycle. By storing an Indicator indicating the start of a simulation cycle and the actual start time, the error 
check module 28 for the object can determine if the controller is properly executing. The controller 26 next 
10 detemnines which subobjects should be run by examining 142 a list of subobjects from which data is 
required. This list is preferably an ordered list since a first subobject may produce data that is used by a 
second subobject. This list can indicate 143 and 144 that a subobject should be run for every time 
increment, every other tfme increment or when a predetermined amount of time has passed since the last 
execution of the subobject. This allows the execution of the subobjects to be tailored to the aging process 
75 for the subobjects. For example, if an object such as a turbine rotor blade degrades significantly enough in 
one year to require a life expectancy determination calculation while the simulation time increment is one 
day then the object for simulating the turbine blade need only be executed every 365 time increments. As 
will be discussed later, the user can also limit the objects in a system that are simulated to a desired subset 
by flagging the objects as not to be executed. For example, if the system includes the entire nuclear power 
20 plant and the user only wants to simulate the reactor damping system, only the objects and parent objects 
related to the reactor damping system are executed. Once the list of subobjects to run is examined and the 
subobjects are designated, the process runs 145 the subobject one at a time by conventionally providing 
execution command messages to the operating system allowing processes that need data from another 
process to run and finish before the needing process is started. The controller module 26 then waits 146 for 
25 interrupts from the subobject indicating that they have completed. When an interrupt occurs the process 
flags 147 an object entry in the subobjects list to indicate the subobject has completed execution. This 
flagging as complete at step 147 occurs even if the error check module 28 is the module providing the 
interrupt. As will be discussed in more detail later with respect to Fig. 8, the en-or check module 28 can 
provide an interrupt whenever it detects that an error has occun-ed, even in a subobject, and set an en-or 
30 flag which is acted upon by this controller module (see steps 149 and 150). It is of course possible to 
provide a check of the error flags immediately after the return from the wait and stop if errors are detected. 
The system then checks 148 to determine whether more subobjects need to be run and, if so, returns to 
examine the list again. Once all the subobject processes are completed, the data necessary for the object 
model is available in the common database 68. When the subobject processes are completed, the en-or 
35 flags for the subprocesses are checked 149 and if an error is indicated the process stops 152. This stop will 
occur when the error check module 28 has set an error flag even if all subobject return successfully. If no 
errors are detected, the model module 30 for the object is executed 153 by again providing an execution 
command to the operating system designating the model module to be executed. The system then waits 
154 until the model module 30 has executed. When the object model process 30 is completed, the error 
40 flags for the process are checked 156 and, if an error is indicated 157, the process stops 152. An interrupt 
is provided 158 to the parent object indicating that the object has completed execution. This step also can 
include a step of setting an error check indicator, indicating that the controller 26 has successfully 
completed a simulation cycle, and storing a cycle completion time in the common database 68 for review 
by the error check module 28. The interrupt of the parent is followed by a wait 160 for another execution 
45 cycle in the simulation. If the enror check module is not executing the controller writes 161 error description 
data to common storage 68, terminates 162 the model module 30 and error check module 28 by sending 
an execution stop command to the modules 20 and 30 and terminates the subobject modules in the same 
way. The display screen module will retrieve the error data and produce an appropriate message. 

Fig. 6 illustrates the structure and execution of a model module 30 contained within each object. This 
50 modeling module 30 is preferably written in an expert system language such as OPS5 with calls to 
FORTRAN routines for performing equation executions. Appendices A-D have been provided herewith that 
provide examples of 0PS5 modules for a pump model module (appendix A) and a pump shaft model 
module (appendix B) and FORTRAN routines for performing calculations for components using component 
equations (appendix C) and subcomponents using subcomponent equations (appendix D) when called by 
55 the modules. Even though the controller routine 26 which starts this routine is written preferably in 
FORTRAN, the start of this routine is handled in the same way by sending a message to the operating 
system designating the process to be executed. The OPS5 language will execute ail the rules in the module 
at the same time without any distinction in order unless the rules are classified in levels and a level 
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execution order is specified. Since the present invention has a preferred order the first section of 0PS5 
module includes execution sequence (level) statements which establish the prefenred execution order. This 
order is set forth inherently in the Rg. 6 flowchart. When the controller module 26 of Fig. 5 starts 170 the 
model module 30 of Rg. 6 the first step by the module is to obtain 172 the needed input data and common 

5 data for the module 30. For enror detection purposes, the model module 30 at this point can set a process 
started indicator along with storing the start time as was described with respect to the controller module 26. 

Once the housekeeping level rules have completed firing, the system fires maintenance rules to 
perform any maintenance on the object which is specified by the maintenance schedule. For example, the 
maintenance rules can review the maintenance schedule in the common database 68 and determine that an 

10 inspection discovered premature degradation of the oil lubricating a turbine and thus reduce the useful life 
by 20% and change the degradation constants in the degradation equation to simulate faster degradation of 
the oil. Appendices A and B include examples of maintenance rules for a pump and a pump shaft. For 
example, consider a pump shaft and the bearing for that shaft. At a point during a simulation the state of the 
bearing and shaft are determined. The states are extrapolated using the bearing and shaft life equations to 

IS be discussed in more detail later. Assume that the next state determination indicates the bearing is bad and 
that maintenance is not scheduled until some time later. As a result, the bearing wilt remain bad until It is 
replaced. The shaft rules have an input that considers bearing quality, now bad, and will detemnine that the 
wear rate on the shaft is now high. If the bearing is replaced, the age of the bearing as set to zero and the 
condition set to good and the rules determine that the state of the bearing is good. During the interval 

20 between the bearing going bad and t)eing replaced the shaft is wearing at an accel erated rate. When the 
bearing is replaced the shaft rules will detennine that the shaft wear rate is normal, unless too much time 
has passed and the shaft has been declared bad or other effects which prevent a normal shaft condition are 
created by other components. It is possible that the accelerated aging of the shaft will cause the shaft to go 
bad before the shaft scheduled maintenance and if this happens the bad shaft will affect other components 

25 or the entire pump. 

The failure of the bearing before the scheduled maintenance acts as a recommendation that the bearing 
be replaced in the Immediately preceding scheduled maintenance outage. In this situation there is always a 
concern about the accuracy of the prediction and the inherent recommendation made by the prediction of a 
failure. The level of accuracy required in a nuclear power plant is bound by the time window defined by 

30 refueling outages. This is approximately 1 to 1 .5 years. In such a plant it is preferable that all maintenance 
be performed during the scheduled outages versus bring the plant down for an unscheduled or forced 
outage due to the unexpected failure of a system or component or due to the need to perform preventive or 
con-ective maintenance. In such a situation the present invention is required to predict between which 
outages an object will likely fail or require maintenance rather than determine the exact date of failure. The 

35 system does attempt to accurately predict the actual date of failure, however, the accuracy depends on the 
accuracy of the object model and the accuracy of the data concerning initial conditions. The determination 
of when to take action is left for the user to decide. The present invention will tell the user the last possible 
date on which to perform maintenance to avoid a failure. This date will be before the failure is actually 
expected to occur. The user would nonnnally be expected to perform the recommended maintenance 

40 activity at the outage prior to the predicted failure. 

The firing of maintenance rules is continuously executed until all are satisfied 176 after which state 
determination rules 178 are fired. An example of several state determination rules which not only require 
input data directly but data previously produced by a subobject are illustrated in appendices A and B. Once 
all the state determination rules are satisfied 180 the model module starts or calls 182 FORTRAN equation 

45 routines which performs the deterministic, and/or statistically based, and probabilistic calculations to 
simulate the changes in the state of the object required for the current time period. The calling of the 
FORTRAN routines is performed by a standard call statement in 0PS5 such as CALL AGEROUTINE 
<V17><V27><V37> which will call an age routine that needs variables V1-V3. Of course the routine must 
be compiled and linked with the program. The passing of variables down to a FORTRAN routine by an 

50 0PS5 routine is accomplished using variables. However, passing variables up to an OPS5 routine by a 
FORTRAN routine requires creating and using working memory elements or variables within the calling 
routine. Examples of this are shown in the appendices. An example of equations which uses not only input 
data directly provided to the object but also Input data provided by the subobjects to determine the life of 
an object and the risk of failure of the object are illustrated in appendices C and D. Once the simulation oi a 

55 change in state of Mine component for the current time period has occunred the module fires 184 
recommendation mles which provide maintenance recommendations to the user. In effect the model 
module performs diagnostics to determine if any of a list of recommendations should be issued. The 
maintenance module issues confirmations of the completion of maintenance activity. In both situations the 
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text is stored in the common storage 68 and the display module subsequently accesses and displays the 
text. Examples of recommendation rules for a pump and a shaft are illustrated in the appendices. 

Once all the recommendation rules are satisfied 186 the results are output 188 to common storage 68 
followed by an interrupt being transmitted 190 to the controller for the object. The results of a single cycle 
5 of the simulation are used as the initial conditions of the next cycle. This particularly is applicable to time 
related data. However, as the simulation progresses these variables can be modified by the user or other 
external data. For example, the time increment can be changed during a simulation to provide a period of 
higher or lower resolution allowing the simulation to skip over less interesting events and simulate 
interesting events in great detail. An example of other data from external sources which is not carried from 

10 cycle to cycle is maintenance schedules. 

The routine then performs appropriate housekeeping and clean up duties 182 such as setting variables 
to initial values and then waits 194 for an Interrupt from the associated controller. This housekeeping also 
includes setting a process finished indicator and the completion time for analysis by the error check 
module. When an Interrupt occurs the execution cycle starts again. 

IS To enhance the modularity of the modeling system the model module 30 is preferably organized in 
distinct separate sections which will allow a standard model module template to be easily updated for any 
new objects that need to be added to the system. A preferred arrangement for the standardized model 
module is illustrated in Fig. 7. The preferred arrangement includes initiation and housekeeping and 
execution sequence rules at the beginning followed by internal data storage areas 212 with input routine 

20 rules 214. Next, maintenance 216 and state determination 218 rules follow, while equation routine calls 220 
follow the state determination rules. Next recommendation rules 222 are followed by output routines 224. Ail 
interrupt handling and initiation rules are grouped together followed by cleanup type housekeeping 228. 
Next come the equation subroutines 230 which are called by the calls 220. 

The rules and equations as discussed above for objects other than a pump and a shaft can be 

25 developed by a component engineer of ordinary skill who is familiar with the object being modeled. As an 
alternative an ordinarily skilled knowledge engineer could query the component engineer and develop the 
rules and equations, A standardized arrangement such as illustrated In Rg. 7 will enhance the ability of the 
present invention to expand and handle any desired number of objects in a system being modeled. To 
further enhance modularity the common data area 68 Is also organized in a modular way. Preferably each 

30 object is provided a fixed size initial conditions and operating parameters data storage area within the 
common data storage 68. Within the storage area predefined storage areas which have associated variable 
names. For example, a storage area for the useful service remaining for a shaft would be prereserved and 
given a name such as Shaft-Useful Service. By scanning the variable names a desired data storage area for 
an object can be found. By providing the common data storage area with fixed size object storage areas, 

35 loading the data into arrays which will increase operating speed is facilitated. 

The error check module 28 in each object is Illustrated in Fig. 8. The goal of the en-or checking routine 
Is to determine whether the various modules which interact with the object and upon which the object 
depends are properly executing. During the initial cycle of the en'or check routine, that is, after execution 
has been started 240 by the routine of Rg. 3, the en-or check module 28 schedules 241 timed wake up 

40 interrupts for interrupts at specified real times. For example, an inten'upt every ten seconds. The process 
then enters a wait state 242 waiting for these interrupts. 

Once an interrupt occurs the process checks 244 the controller. This check Is performed by checking 
the started and finished process indicators for the object controller and determining the elapsed time for the 
started controller process. If the time of execution for the controller module Is beyond a predetermined 

45 amount this indicates that the module is stuck in a loop or that an object process which the controller Is 
waiting on is stuck. This is an error. Another type of error is a condition where the controller module has not 
executed within a predetermined time from the start of a simulation. If an error has occurred 245. the 
module 28 writes appropriate error condition description data into common storage 68. The display module 
18 will later retrieve this information and produce a message describing the error on the display screen. 

60 Next the en-or checker 28 sets 248 the error flag and then interrupts 249 the object control module 26 when 
interrupted, as illustrated in Fig. 5. the module 26. will check the en'or flag and terminate Itself. After 
interrupting module 26, the error check module 28 terminates the model and subobject controllers and itself 
253. Next the routine performs the same sort of check on the model module 30 and If there Is an error 256 
notifies the controller in the manner previously discussed. Next the routine checks 257 the controllers of the 

55 subobjects which are being controlled by the object controller by accessing the list of executing processes 
designated by the object controller. Once again, if an error is detected 258 the controller 26 is notified. 

The user control routine 16 allows the user to set initial conditions, change maintenance schedules, 
interrupt the simulation and perform unscheduled maintenance and select which objects are to be simulated 
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in a run. and the operation of this routine is depicted Fig. 9. Once this routine is started by the user the user 
is provided a display 272 of available options followed by entry of the routine into a wait state 274 where 
the process waits for an option selection. When the interrupt is exited an option determination 276 is 
performed followed by processing of the option. For example, if the option selected by the user is to update 

5 maintenance data, the processing of the option would retrieve the maintenance file and allow the user to 
change the contents of the maintenance file. If the user selects an option for designating a subset of the 
objects in the system to be simulated, the common database 68 is scanned to determine the names of the 
objects available from the tags in the database. The list of objects is provided to the user and the user 
marks those for which a simulation is required- The list must include the desired target object and all 

10 associated parents up to and including the supervisor module 14. For example, if the turbine pump object is 
the object of simulation interest, it is marked as one of the objects. The list of objects to be run must also 
include the turbine object of which the pump is a subobject. the plant object of which the turbine is a 
subobject and the supervisor. If the plant object also has as subobjects the generator, the boiler and the 
power distribution systems, these systems would not be marked for execution. Each object examines uses 

IS this list as previously discussed with respect to Fig. 5. The objects then uses this flagged list to decide 
whether they should execute as previously mentioned. The user can also be given the option to select 
various modes of outputting the results such as producing displays that show the life profile, safety margin, 
trip margin, expected life, wear rate maintenance and elapsed simulation time when for example simulating 
components of a nuclear power plant. Once this option is processed the user is given the option to select a 

20 new display 280 and. if no new displays are selected, any functions selected by the user are performed. 
For example, the user could stop an execution, change the maintenance data and request a simulation from 
the original initial conditions. The functions performed would then be updating of the maintenance data and 
initiation of a simulation. 

The screen display routine 18 illustrated In Rg. 10 performs conventional display functions using 

25 conventional virtual display techniques. During the first cycle of the screen display module, a generic 
display for the entire system is created 292 along with virtual object displays 294. The system also creates 
graphic shells for plotting the results and then, based on user input, determines which initial object will be 
displayed. For example, the user can specify, during the user control module 16 execution, that only the 
water chemical make-up system is to be simulated and that only the life profile of a boron concentration 

30 analyzer is to be displayed. From this determination appropriate windows into the virtual display are 
designated 300 and the user is provided with an appropriate display. The system then enters a wait state 
302 wating for the supervisor to indicate that a simulation time increment has been completed. When an 
interrupt occurs the system detemnines 304 whether the simulation is finished, if so the system stops 306. If 
the user wishes to display a new object, then the old windows are deleted 310 followed by the creation of 

35 new windows and plotting 314 of the output result data for the object windows. If a new object is not 
desired, a determination is made as to whether a new profile of the objects is desired and. if so. the 
windows are again deleted and new ones created. 

The maintenance module 20 illustrated in Rg. 11 starts by obtaining 322 the maintenance schedule 
from the common database 68. Preferably, the maintenance schedule for each object is stored in the 

40 dedicated storage area for the input data and output results for the object previously mentioned. The 
schedule is compared with the cun-ent simulated time for each object on the list. If there is a match 326 for 
a particular object the maintenance indicator for that object is set so that the maintenance rules in the 
object can perform the appropriate maintenance. For example, the maintenance indicator can Indicate 
complete replacement of the object, rebuilding or repair or refurbishment of the object and for each one of 

45 these different types of maintenance, a different improve ment in component life expectancy, reliability, etc. 
is caused. If all the objects of the maintenance schedule have not been compared to the current time the 
routine returns for more comparisons. When all the comparisons have been completed the supervisor 14/50 
is Internjpted allowing the supervisor to initiate a new simulation run. Once the supervisor is interrupted the 
process waits 334 for an inten-upt from the supen/isor indicating another maintenance cycle is necessary. 

50 TTie system can provide various types of displays as illustrated in Figs. 12 and 13. The display of Fig. 
12 shows the profile for changes in risk level in a plant from a situation where no maintenance is performed 
and a situation where maintenance is performed three times on the components of the plant This type of 
display will allow the user to very effectively determine the cost risk ratio associated with various 
maintenance plans. Rg. 13 shows the life profile, wear rate, expected life and safety margin of for a pump 

55 along with the life left and wear rate of the components which make up a pump. 

The present invention provides the capability to optimize plant operations, safety, and performance. It 
provides the capability to perfonm analyses of the different systems and components by varying operating 
modes and conditions, safety and trip goals, maintenance and part quality, and scheduled maintenance. 
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replacement, test, and inspection intervals. The analysis allows a prediction about the effect on safety, 
performance, and life extension. The modeling system enables the optimal maintenance, replacement, test, 
and inspection intervals for the various systems within the plant to be determined and implemented. The 
overall benefits of the invention when applied to a power plant system include reduced forced outages, 

5 improved safety, reduced outage durations, and improved planning. 

Currently, to change operating conditions during a simulation the following steps are taken. First a set of 
operating conditions that the system will access during the simulation is created. The simulation is started 
and paused at the point in the simulation when a change in operating conditions is desired. The operating 
condition data is then replaced or updated and the simulation is continued. It is possible to have the 

70 databases used during the simulation to be automatically switched. This could be accomplished by having 
an operating conditions schedule that is checked at the same time the maintenance schedule is checked. 
This schedule could be used to load in a designated new operating conditions database. 

As previously mentioned, blank stubs are provided in the modeling system to reserve space in the 
modeling system for additional modules. A blank stub has all the basic input/output variables and 

75 declarations necessary to provide the minimum processing or calculations necessary to return any 
processed data to the calling program in which the stubs are inserted. For example a system level module 
can be created having a model of a pump, piping and valves. By providing blank stubs in the system level 
model the system can be exercised and tested because the blank stubs provide return valves where the 
pump, piping and valve modules will reside. The stubs may simply accept and return fixed data, thereby 

20 emulating all processing by and communications to and from the stubs. For example, a subprocess stub, as 
represented In pseudo code, could be: 

Sub-Process Valve 

Get all data from calling process 
Add 1 to all data 
Return Data 
End Sub-Process Valve 



A model stub, as represented in pseudo code could be: 

35 Sub-'Process Valve 

Get all data from calling process 
Pressure = log (T+P)/g 



25 



30 



40 



Call (Subroutine A, C) 
Add 5 to all temperature data 
Flow - Flow + % Open 
Return Data 
End Sub-Process Valve 

This stub would calculate a pressure from the variables that determine pressure in a valve, call a 
subroutine that typically calculates life of the valve, add 5" to the temperature data for the valve and 
increase the flow by the percent the valve is open. The stub would thereby provide varying data for all 
parameters of a valve. 
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1. A system for controlling and managing the operation of a plant having a plurality of subsystems and 
components for which predetennined data is input to the plant operating system, said plant operating 
system having predetennined operating elements including a modeling system that is characterized by: 
supervisory means for performing supervisory functions of the system; and 

object means for modeling objects in the plant responsive to a simulation cycle initiated by said supervisory 
means, said object means comprising object models where each object model comprises modeling means 
for deterministically, probabilistically and heuristically modeling the object. 

2. A plant operating system as recited in claim 1 . further characterized by a common database to which all 

object models have access. 

3. A plant operating system as recited in claim 2, wherein said modeling system is further characterized by: 
expert maintenance determination means for changing the state of the object responsive to maintenance 



expert state determination means for determining a current state of the object: 
state change equation means for determining the change of state of an object from the current state; and 
75 expert recommendation means for providing recommendations for state changes. 

4. A plant operating system as recited in claim 3, wherein said object models are arranged in a hierarchy 
requiring execution completion of lower levels of the hierarchy before upper levels can complete execution. 

5. A plant operating system as recited in claim 4. wherein an upper level object model controls a lower level 
object model execution sequence. 

20 6. A plant operating system as recited in claim 5. wherein each object model further comprises: 

controlling means for performing execution control functions for the object; and 

error determination means for determining whether the object model is functioning correctly. 

7. A plant operating system as recited in claim 5, wherein said supervisory means, said controlling means. 

said error determination means and said modeling means are independently executing processes. 
25 8. A plant operating system as recited in claim 5. wherein said controlling means includes an execution 

sequence ordered list of lower level object models. 

9, A plant operating system as recited in claim 6, wherein a user designates a subset of said hierarchy and 
said controlling means controls execution responsive to the subset. 

10. A system for controlling and managing the operation of a plant having a plurality of subsystems and 
30 components for which predetermined data is input to the plant operating system, said plant operating 

system having predetermined operating elements including a modeling system that is characterized by: 

supervisory means for performing system supervision; 

a common database accessible by said supervisory means; and 

a hierarchical object model tree having object models executing bottom to top and each of said models 

35 comprising; 

modeling means for modeling a corresponding object and including: 

expert maintenance means for changing the state of the corresponding object responsive to a maintenance 

schedule; 

expert state determination means for determining a current state of the corresponding object; 
40 state change equations for determining a future state of the object from the current state; and 
expert recommendation means for providing recommendations for state changes; 

controlling means for initiating an ordered execution of objects lower in the hierarchy prior to initiating 
execution of said modeling means; and 

error determination means for determining whether said modeling means and said controlling means are 
45 executing. 
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@ The present plant operating invention employs a 
modeling system that arranges the model in a hier- 
archical structure of communicating and indepen- 
dently executing object modules controlled by an 
overall supervisor. Each object represents a compo- 
nent or a system and includes an object controller 
which communicates with other object modules, an 
object error checker and an object model. The ob- 
jects communicate through a database accessible by 
all objects. The structure of the object module and 
the hierarchical structure itself are standardized al- 
lowing new components or systems to be added by 
adding a standard object module which includes an 
object model that is unique to the object being 
modeled. The controller for an object causes subob- 
jects upon which the object model depends for data 
to be executed prior to execution of the object 
model. Such bottom up model traversal insures that 
models do not execute until all needed data is 
available. The error check module checks the con- 
troller and model modules to make sure they are 



executing properly. The object model includes a 
deterministic equation based component aging 
model, a statistical based component aging model 
and expert rules that combine the deterministic and 
statistical model with the knowledge of experts to 
determine the current state of the object and make 
recommendations concerning future actions concern- 
ing the object. A maintenance module is also in- 
cluded along side the supervisor that allows main- 
tenance actions for the objects to be taken into 
consideration. 
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